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(57) Abstract 



An efficient real-time transport protocol multiplexing method and apparatus for transporting compressed speech between IP telephony 
gateways. The protocol eliminates bandwidth usage inefficiencies in transporting short packets between nodes connected by an IP network, 
wherein the method and apparatus enables a number of users to share a single RTP/UDP/IP connection. The protocol includes creating a 
header for a plurality of data packets, each header providing identification of a user associated with a packet, adding each header to the 
data packet associated therewith to form mini-IP payloads, multiplexing the mini-IP payloads into a RTP payload and transmitting the RTP 
payload over a single RTP/UDP/IP connection. 
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METHOD AND APPARATUS FOR PROVIDING USER MULTIPLEXING IN A REAL-TIME PROTOCOL 



5 BACKGROUND OF THE INVENTION 

1. Field of the Invention , 

This invention relates in general to a IP telephone, and more particularly to a 
method and apparatus for providing efficient user multiplexing in a real-time 
protocol pay load for transporting compressed speech between IP telephony 
10 gateways. 

2. Description of Related Art . 

An organization's computer network has become its nervous system. 
Organizations have combined desktop work stations, servers, and hosts into Local 
Area Network (LAN) communities. These Local Area Networks have been 
1 5 connected to other Local Area Networks and to Wide Area Networks (WANs). It 
has become a necessity of day-to-day operation that pairs of systems must be able 
to communicate when they need to, without regard to where they may be located in 
the network. 

During the early years of network computing, proprietary networking 
20 protocols were the standard. However, the development of the Open Systems 

Interconnection Reference Model introduced by the International Organization for 
Standardization (ISO) has led to an impressive degree of interworking, which 
generally allows end-user applications to work very well between systems in a 
network. Implementations are based on written standards that have been made 
25 available by volunteers from dozens of computer vendors, hardware component 
vendors and independent software companies. 

During the last decade, LANs have been proliferating. This has created a 
recurring problem of how to minimize congestion and optimize throughput that must 
be solved by network managers. An early solution was to simply divide Local Area 
30 Networks into multiple smaller networks serving smaller populations. These 
segments were connected by bridges to form a single Local Area Network with 
traffic being segregated locally to each segment. 

An Internet is a set of networks connected by gateways, which are sometimes 
referred to as routers. The Internet Protocol (IP) is a network layer protocol that 

1 
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routes data across an Internet. The lntemet Protocol was designed to accommodate 
the use of host and routers built by different vendors, encompass a growing variety 
of growing network types, enable the network to grow without interrupting servers, 
and support higher-layer of session and message-oriented services. The IP network 
5 layer allows integration of Local Area Network "islands". 

The Internet not only provides a medium for data transport, but also has 
developed as a medium for telecommunications. In fact, IP telephony is maturing as 
a technology and a service, which places it in direct conflict with the conventional 
public telephone network. New types of IP telephony equipment are being 
introduced and small Internet service providers and niche carriers are beginning to 
offer IP telephony services. 

However, while IP telephony, or voice-over-IP, has great potential to 
compete against the traditional public voice network, many obstacles must first be 
overcome. For example, the quality of Internet telephone calls is not as good as 
15 public network calls. Customer interest in the United States-where long-distance 
prices have consistently fallen-is uncertain. Further, IP telephony network 
equipment is new and lacks features that carriers desire. 

Consequently, only a handful of small telephone companies now offer IP 
telephony services, and the amount of traffic they carry is minimal. However, 
equipment vendors and carriers are moving quickly to overcome these problems and, 
according to analysts, the number of established carriers beginning IP telephony 
trials is rising rapidly, new carriers are jumping into the market and the number of 
services being offered is expected to increase dramatically. In fact, analysts predict 
that users will embrace the new IP-based voice services. 

Accordingly, the success of Internet has further consolidated the notion that 
IP is the dominant transport protocol in access networks. The penetration of Internet 
and subsequent IP connectivity to homes and businesses have given impetus to 
integrated services over IP which means voice, data and video over a single IP 
network. At present, IP networks offer a single class of service called best effort, 
which can not guarantee any Quality of Service (QoS) to applications. To support 
delay sensitive applications such as voice and interactive multimedia, there have 
been many proposals submitted to the Internet Engineering Task Force (IETF) on 
how to integrate QoS in IP networks. These proposals include differentiated service 
(diff-serv), Integrated services (Int-serv) and Multi Protocol Label Switching 
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(MPLS). Despite these efforts, QoS in IP is still elusive and could take some time 
before it is deployed over global Internet. 

As mentioned above, IP telephone has emerged as a potential application to 
challenge the traditional phone companies by offering long distance telephone 
5 service over Internet for low prices. There are a large number of equipment vendors 
offering IP telephone gateways and accessories to provide IP telephony service to 
corporate customers and Internet Service Providers (ISPs). IP telephone standards 
such as H.323, H.225 and H.245 have been standardized to enhance the rapid 
deployment of IP telephone services in global Internet. Even though, IP telephone is 

10 not a reality in public Internet today, it has been successful in Intranet and Virtual 
Private Networks (VPN) environments. 

There is a strong indication that IP telephone will be a niche service once 
QoS issues in IP networks become a reality. However, IP networks offer only best 
effort service, whereas delay sensitive applications such as voice and interactive 

15 video require a deterministic guarantee on the delay, delay variation and packet loss 
from the network. As can be seen then, this lack of QoS guarantee in IP networks is 
touted as the major problem to provide real time services such as IP telephone over 
Internet. To overcome the delay problem in the Internet, IP telephone providers over 
provision the links (networks) that interconnect IP telephone gateways. This 

20 additional bandwidth enables the IP packets to be transmitted with less delay thus 
providing a reasonable voice quality. It has been demonstrated in Intranet as well as 
VPNs that IP telephone services can match the voice quality offered by traditional 
telephone networks. As a result, the growth of IP telephone gateways in corporate 
and ISP environments is expected to increase exponentially in the coming years. 

25 Traditionally voice is carried in a circuit switched network with connection 

oriented model. The explosive growth of data traffic in the network has changed the 
notion of service specific networks (single network for single service). Voice over 
IP network enables the voice traffic from public branch exchanges (PBX) and public 
switched telephone network (PSTN) users to share the data network thus improving 

30 the network utilization and lowering the cost associated with long distance telephone 
network. IP telephone gateways act as an interface between the existing PSTN and 
PBX networks and IP networks. This method allows one PSTN user to call another 
PSTN user connected through IP telephone gateways thus eliminating the need for 
long distance telephone network. 
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In a IP telephony connection, two sides of the PSTN/PBX users (two 
branches of the same company) are interconnected by IP telephone gateways. In 
such application, a telephone call between PSTN/PBX users located at either side of- 
the gateways is carried by a separate Real-time Transport Protocol/User Datagram 
5 Protocol/Internet Protocol (RTP/UDP/IP) connection. RTP is an Internet protocol 
for transmitting real-time data such as audio and video. RTP itself does not 
guarantee real-time delivery of data, but it does provide mechanisms for the sending 
• and receiving applications to support streaming data. Typically, RTP runs on top of 
the UDP protocol, although the specification is general enough to support other 
1 0 transport protocols. The User Datagram Protocol is a connectionless protocol that, 
like TCP, runs on top of IP networks. Unlike TCP/IP, UDP/IP provides very few 
error recovery services, offering instead a direct way to send and receive datagrams 
over an IP network. _ 

IP telephony gateways provide an interface between the existing circuit 
1 5 switched telephone networks (such as PSTN and GSM) and the packet switched IP 
data networks. In traditional IP telephony applications, telephone calls between 
PSTN users interconnected by a pair of IP telephony gateways to compress incoming 
PSTN speech samples generate packets with sizes ranging from 5 to 20 bytes per 
speech sample. 

20 For example, G.723. 1 (the most popular IP telephony codec and the 

International Multimedia Teleconferencing Consortium's (IMTC) Voice over IP 
(VoIP) mandatory low bit-rate codec), generates a 20 byte speech packet at 30 ms 
intervals. Many codecs used in cellular environment generate less than 10 byte 
packet per speech sample. Small size packets are subjected to large overhead when 

25 transferred using the Real time Transport Protocol (RTP). The RTP/UDP/IP 

overhead is 40 bytes (12+8+20) for a simple speech packet. For example, a 10 byte 
packet transferred via RTP/UDP/IP increases the overhead to 80% (40 byte 
overhead/50 byte overhead plus packet). In addition, for each call request a single 
UDP/EP connection (a pair of UDP ports) is established between the gateways 

30 requiring a large state (memory) to be maintained at the telephony gateways, thereby 
making these less scaleable. 

Congestion in IP networks results in packet loss at routers and UDP does not 
have any retransmission mechanism to recover lost packets. Also, real time 
applications such as speech is intolerant to delay caused by re-transmission. In 

35 traditional RTP method, each individual speech packet is transmitted as a IP packet, 
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which generates a large number of packets between gateways. This heavy traffic 
volume is a potential situation for congestion and packet loss at IP routers. 

It can be seen then that there is a need for a method and apparatus for . 
eliminating inefficiencies in transporting short packets between IP telephony 
5 gateways connected by an IP network. 

It can also be seen that there is a need for a method and apparatus that 
enables a number of users to share a single RTP/UDP/IP connection. 

SUMMARY OF THE INVENTION 

10 To overcome the limitations in the prior art described above, and to 

overcome other limitations that will become apparent upon reading and 
understanding the present specification, the present invention discloses an efficient 
real-time transport protocol multiplexing method and apparatus for transporting 
compressed speech between IP telephony gateways. 

1 5 The present invention solves the above-described problems by providing a 

method and apparatus for eliminating inefficiencies in transporting short packets 
between IP telephony gateways connected by an IP network, wherein the method and 
apparatus enables a number of users to share a single RTP/UDP/IP connection. 

A protocol in accordance with the principles of the present invention includes 

20 creating a header for a plurality of data packets, each header providing identification 
of a user associated with a packet, adding each header to the data packet associated 
therewith to form mini-IP payloads, multiplexing the mini-IP payloads into a RTP 
payload and transmitting the RTP payload over a single RTP/UDP/IP connection. 
Other embodiments of a system in accordance with the principles of the 

25 invention may include alternative or optional additional aspects. One such aspect of 
the present invention is that the plurality of data packets are received from two or 
more users. 

Another aspect of the present invention is that the identification of a user 
further comprises a unique channel identifier for each of the two or more users. 
30 Another aspect of the present invention is that the channel identifier is 

assigned to packets from a user when the user requests access to the IP telephone 
network. 

Another aspect of the present invention is that the header comprises a length 
indicator, the length indicator indicating the size of the data packet associated with 
35 the header. 
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Another aspect of the present invention is that the length indicator comprises 
six bits for allowing a maximum of a thirty-two byte data packet. 

Another aspect of the present invention is that the header further comprises a 
sequence number, the sequence number marking data packets transmitted from a 
5 user to identify data packet loss. 

Another aspect of the present invention is that the sequence number further 
comprises two bits, the two bits identifying a maximum of three consecutive data 
packet losses. 

Another aspect of the present invention is that the header of each data packet 
1 0 multiplexed into the RTP pay load is transparent to intermediate IP routers. 

Another aspect of the present invention is that the protocol further includes 
de-assembling the RTP payload back into the data packets^ 

Another aspect of the present invention is that the protocol further includes 
receiving at a local gateway an access request from a user at a remote IP gateway, 
1 5 transmitting a setup message to the remote IP gateway using an IP connection and 
establishing a user plane connection for receiving data packets from a user after 
successful completion of a connection setup. 

Another aspect of the present invention is that the protocol further includes, 
after receiving an access request from a user, determining whether an existing 
20 RTP/UDP/IP connection is available, using an existing RTP/UDP/IP connection 
when an existing RTP/UDP/IP connection is determined to be available, creating a 
new RTP/UDP/IP connection when an existing RTP/UDP/IP connection is 
determined not to be available and creating a setup message using a local UDP port 
number, remote port number, channel identifier. 
25 Another aspect of the present invention is that the protocol further includes 

recovering, at the remote gateway, a local UDP port number, remote port number, 
channel identifier from the setup message, verifying at the remote gateway whether 
the channel identifier is free and accepting the connection when the channel 
identifier is free. 

30 Another aspect of the present invention is that the accepting the connection 

further includes updating a channel identifier table at the remote gateway and 
replying to the local gateway with a connect message. 

Another aspect of the present invention is that the protocol further includes 
replying to the local gateway with a rejection message when a problem allocating the 

35 connection occurs. 

6 

BNSDOCID: <WO 0011849A1J_> 



WO 00/1 1 849 PCT/US99/1 7389 

Another aspect of the present invention is that the protocol further includes 
receiving at the local fentity the connect message, confirming at the local entity the 
channel identifier and informing the user requesting access. 

Another aspect of the present invention is that the protocol further includes 
5 controlling the multiplexing arid transmitting of the RTP payload using a timer. 
Another aspect of the present invention is that the data packets include 
compressed voice data. 

An IP telephone network according to the present invention includes a 
remote IP gateway and a local IP gateway, wherein the remote and local IP gateways 
10 communicate using the protocol. 

A MINI-IP controller according to the present invention includes means for 
providing control plane signaling, control plane signaling being used to setup a 
connection to a remote peer MINI-IP controller and means for=providing user plane 
signal, user plane signaling being used to transmit data packets to a user associated 
1 5 with the remote peer MINI-IP controller using the protocol. 

An RTP payload according to the present invention includes an RTP header, 
a plurality of data packets representing data from , a plurality of users and a plurality 
of MINI-IP headers, each of the plurality of packets having a MINI-IP header 
attached thereto, each of the MINI-IP headers comprising a user identifier for 
20 identifying one of the plurality of users being associated with each of the packets, 
and each MINI-IP header and packet combination forming a MENI-IP payload, the 
MINI-IP payloads being multiplexed together to form a RTP packet. 

A base station, base station controller and mobile switching center according to 
the present invention include a MINI-IP controller that eliminates inefficiencies in 
25 transporting packets using the MINI-IP protocol. 

These and various other advantages and features of novelty which characterize 
the invention are pointed out with particularity in the claims annexed hereto and form a 
part hereof. However, for a better understanding of the invention, its advantages, and 
the objects obtained by its use, reference should be made to the drawings which form a 
30 further part hereof, and to accompanying descriptive matter, in which there are 
illustrated and described specific examples of an apparatus in accordance with the 
invention. 
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BRIEF DESCRIPTION OF THE DRAWINGS 
Referring now to the drawings in which like reference numbers represent 
corresponding parts throughout: 

Fig. 1 shows an application scenario in which two sides of the PSTN/PBX 
5 are interconnected by IP telephone gateways; 

Figs. 2a-b illustrate MINI-IP headers according to the present invention; 
Fig. 3 illustrates the multiplexing of MINI-IP payloads in a RTP packet 
using the MINI-IP header; 

Fig. 4 illustrates the location of the MINI-IP controller in a IP telephone 
10 layered model; 

Fig. 5 illustrates the user plane and control plane in a MINI-IP gateway 
environment; 

Fig. 6 illustrates an example of a CID table; 

Fig. 7 illustrates the use of the TIMERJVTUX according to the present 
15 invention; 

Fig. 8 illustrates the application of MINI-IP being restricted to transport 
voice users between IP telephony gateways; 

Fig. 9 illustrates the application of a MINI-IP controller in a radio access 
network; 

20 Fig- 10 is a plot of the number of users on a single RTP/UDP/IP connection 

versus the bandwidth in Kbps for G.723 . 1 ; 

Fig. 1 1 is a plot of the number of users on a single RTP/UDP/IP connection 
versus the bandwidth in Kbps for G.729; and 

Fig. 12 illustrates a comparison of the percent overhead verses the number of 
25 users for different methods. 



DETAILED DESCRIPTION OF THE INVENTION 
In the following description of the exemplary embodiment, reference is made 
to the accompanying drawings which form a part hereof, and in which is shown by 
30 way of illustration the specific embodiment in which the invention may be practiced. 
It is to be understood that other embodiments may be utilized as structural changes 
may be made without departing from the scope of the present invention. 

The present invention provides a an efficient method and apparatus for 
transporting short packets such as compressed speech packets between IP telephony 
35 gateways connected by a IP network. The present invention enables a number of 
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low bit rate connections (compressed speech) to share a single RTP/UDP/IP 
connection, thus reducing the RTP/UDP/IP overhead. A MINI-IP header (2 byte) is 
added to each packet from an user before it is assembled with packets from other 
users into an RTP payload. To identify individual users on a single RTP/UDP/IP 
5 connection, a unique Channel Identifier (CID), as a part of the header, is proposed. 
Channel ID negotiations between the peer gateway entities is carried out by a new 
signaling procedure called MINI-IP signaling. Analytical results show that the 
MINI-IP method reduces the overhead for short packets by 60% thus improving the 
bandwidth efficiency. Other advantages of the present invention include a decrease 

10 in the number of UDP/IP connections between gateways and a decrease in the traffic 
congestion at intermediate IP routers. The present invention may be implemented, 
for example, in IP telephone gateways, Radio Access Network (RAN) access nodes, 
and IP access nodes by simply adding an external MINI-IP control module. The 
MINI-IP method uses the existing bearer protocols such as RTP, TCP, UDP ad IP 

1 5 and does not require any changes to the traditional IP network functionalities. 

Traditionally voice is carried in a circuit switched network with connection 
oriented model. The explosive growth of data traffic in the network has changed the 
notion of service specific networks (single network for single service). Voice over 
IP network enables the voice traffic from PBX and PSTN users to share the data 

20 network thus improving the network utilization and lowering the cost associated 
with long distance telephone network. IP telephone gateways act as an interface 
between the existing PSTN and PBX networks and IP networks. This method 
allows one PSTN user to call another PSTN user connected through IP telephone 
gateways thus eliminating the need for long distance telephone network. 

25 Fig. 1 shows an application scenario 100 in which two sides of the 

PSTN/PBX 100, 1 12 (two branches of the same company) are interconnected by IP 
telephone gateways 120, 122. In such an application, a telephone call between 
PSTN/PBX users 1 10, 1 12 located at either side of the gateways 120, 122 is carried 
by a separate RTP/UDP/IP connection. The codecs used at the telephone gateway to 

30 compress incoming PSTN/PBX voice calls generates packets with a size ranging 
from 5 to 20 bytes. 

For example, the IP telephone standard G.723.1 specifies a codec that 
generates a 20 byte packet at the interval of 30 ms speech sample. Many codecs 
used in cellular environments generate a small packet, e.g., on the average a 10 byte 
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packet per speech sample. This small size packets require a large overhead when 
they are transferred using the Real time Transport Protocol (RTP). 

The RTP/UDP/IP overhead is 40 bytes (12+8+20) for each speech packet. 
For example, if a 1 0 byte packet is transferred via RTP/UDP/IP then the overhead is 
5 80%, i.e., 40/50. In addition, for each call request a single UDP/IP connection is 
established between the gateways 1 20, 1 22 requiring a large number of states 
(memory) to be maintained at the telephone gateways 120, 122. 

Congestion in IP networks results in packet loss at routers and UDP does not 
have any retransmission mechanism to recover lost packets. Also, real time 

1 0 applications such as speech are intolerant to delay caused by re-transmission. In a 
traditional RTP method, each individual speech packet is transmitted as a IP packet, 
which generates a large number of packets between gateways. This heavy traffic 
volume is a potential situation for congestion and packet loss atlP routers. 

The large overhead to transfer a small packets (compressed speech) through 

1 5 RTP/UDP/IP has been one of the drawbacks of IP telephone. In order to minimize 
the overhead, RTP/UDP/IP header compression is applied for slow speed links. 
However, this method requires compressing/decompressing at routers as well as 
some additional processing overhead. 

Figs. 2a-b and 3 illustrate the use of MINI-IP headers to reduce header 

20 overhead according to the MINI-IP protocol. According to the present invention, no 
compression is utilized, yet an equal or better bandwidth efficiency is achieved. 
Overhead is reduced by multiplexing two or more (e.g., up to 256) low bit rate 
connections in a single RTP/IP/UDP connection using a MINI-IP header 202 as 
illustrated in Fig. 2a. Alternatively, overhead may be reduce using the MINI-IP 

25 header 204 illustrated in Fig. 2b. However, those skilled in the art will recognize 
that the present invention is not meant to be limited to the particular MINI-IP 
headers illustrated in Figs. 2a-b, but that the MINI-IP headers 202, 204 illustrated in 
Figs. 2a-b are presented for illustration only. Rather, those skilled in the art will 
recognize that the MINI-IP headers 202, 204 enables multiplexing of multiple small 

30 size packets, and is added to each mini packet before it is assembled with other mini 
packets as an RTP payload, as illustrated in Fig. 3. 

To identify a single user among the number of users sharing the RTP 
connection, each user is allocated an unique Channel Identifier (CID) which is 
negotiated during connection setup. The CID negotiation procedures is carried out 

35 by MINI-IP signaling, which uses a TCP/IP connection for reliable transport. The 

10 



BNSDOCID: <WO. 



_0011849A1J_> 



WO 00/1 1 849 PCT7US99/1 7389 

most suitable application scenarios for MINI-IP method include IP telephone 
gateways connecting PSTN/PBX/GSM users. 

To identify mini packets multiplexed on a single RTP pay load, MINI-IP uses 
a two byte header, called MINI-IP header, for each mini packet. The MINI-IP 
5 header 202, as shown in Fig. 2a includes a Channel Identifier (CID) 210, a Length 
Indicator (LI) 212, and a Sequence Number (SN) 214. The MINI-IP header 202 
allows many users to share a single RTP/UDP/IP connection thus reducing the 
RTP/UDP/IP overhead per packet. 

As illustrated in Fig. 2a, the MINI-IP header includes a CID field 210, which 

10 identifies a single user among users haring a single RTP/UDP/IP connection. A CID 
210 is assigned at the time of the request for access to the IP network and it is 
unchanged throughout the connection time. The length of the CID field 210 is 8 
bits, which limits the number of users per single RTP connection to 256. 

The LI field 212 indicates the size of the pay load (speech packet) and the 6 

1 5 bits allow a maximum of 64 byte pay load. The variable size of the LI field 212 
allows different codecs to share a single connection and offers the flexibility to 
transport any low bit rate connection using MINI-IP method. The size of the LI 
field 212 is limited to 64 bytes since most of the codes available today (G. 723.1, 
G.729) generates packets less than 20 bytes per speech sample. 

20 The 2 bit Sequence Number (SN) field 214 is used for marking the voice 

packets transmitted from a single user in modulo 4 method, which can be used at the 
receiver to identify any packet loss. The module 4 scheme will be able to identify up 
to 3 consecutive packet losses at IP layer. 

The MINI-IP header 204, as shown in Fig. 2b includes a Channel Identifier 

25 (CID) 210, a Length Indicator (LI) 212, a Transition bit (T) 216 and a Reserved bit 
(X) 218. The Channel Identification (CID) 210 in Fig. 2b is an 8 bit field which 
allows a maximum of 256 users to share a single RTP/UDP/IP connection. When 
the total number of users exceeds 256, a new RTP/UDP/IP connection is established. 
The LI field 212 is a 6 bit field which allows a maximum pay load size of 64 bytes. 

30 The Transition bit (T) 21 6 is used to identify any change in processing that was 
applied to a mini-packet. Notification of such changes occurs by toggling the bit. 
Finally, the Reserved bit (X) 21 8 is currently undefined, but may be used, for 
example, as an indication of a header extension and Dual Tone Multi-Frequency 
(DTMF). 
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As mentioned above, those skilled in the art will recognize that the above 
illustration of MINI-IP headers is not meant to limit the invention, but that other 
MINI-IP header configurations and sizes could be used in accordance with the 
present invention. For example, the length of the fields could be modified within the 
5 2 byte format. Further, other fields could be substituted and the length of the fields 
is not meant to be limited to provide a MINI-IP header of 2 bytes. For example, the 
reserved bit illustrated in Fig. 2b may be set to "1" to indicate an extension head is 
included in the MINI-IP header thereby providing an overall length for the MINI-IP 
header of 3 bytes. Alternatively, the reserved bit may be set to "0" to indicate that an 
extension header is not included in the MINI-IP header. Nevertheless, those skilled 
in the art will recognize that increases in the overall size of the MINI-IP header will 
proportionally increase the total overhead when multiple MINI-IP packets are 
multiplexed together in accordance with the invention. Thus, those skilled in the art 
will recognize that any MINI-IP header that enables multiplexing of multiple small 
size packets, is added to each mini packet before it is assembled with other mini 
packets as an RTP payload as illustrated in Fig. 3, and which allows proper 
processing of the multiple mini packets may be used without departing from the 
scope of the present invention. 

The assembly of mini packets into a single RTP/UDP/IP payload 300 is 
shown in Fig. 3. The mini packets 310 follow the RTP header 312 and each mini 
packet 320 is delineated by the two byte MINI-IP header 312. This approach 
requires a simple de-multiplexing algorithm at the receiver. Because the MINI-IP 
header 3 12 in the RTP payload 300 is transparent to the intermediate IP routers, the 
MINI-IP according to the present invention does not cause any problems in terms of 
IP packet forwarding and other functionalities at the IP layer. The traditional Header 
Error Controls (HEC) found in many protocols is excluded because MINI-IP relies 
on the higher layer checksum (UDP checksum) to protect the headers and payload 
from any transmission errors. 

The MINI-IP controller is the key element which will be added to a IP 
telephone gateways to implement the MINI-IP method. The major function of the 
MINI-IP controller are: 

i. Negotiate channel identifier with remote gateway upon a 
connection request 

ii. Multiplex speech packets from a number of users into a single 
RTP payload 
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111. 



IV. 



De-assemble MINI-IP packets from the RTP payload 
Communicate to the remote controller to forward any request 
and/or control message 



5 



The location of the MINI-IP controller 410 in a IP telephone layered model 



400 as shown in Fig. 4. The MINI-IP controller 410 is inserted between the IWF 
function (not shown) of the PSTN/GSM/PBX network 420 and the RTP module 422 
in the IP telephone gateway. The MINI-IP controller 410 is capable of receiving 
connection request from PSTN/GSM/PBX users 420 and setting up a channel on an 

10 existing or a new RTP/UDP/IP connection. The MINI-IP controller 41 0 acts as an 
application to the layers below 422, 424, 426, 428 (RTP/UDP/IP) and uses the bearer 
services offered by the lower layers for effective multiplexing. Other functions of 
the controller include open and close RTP/UDP connections, keep track of the active 
users on all UDP connections, and provide inter-working withJ? STN/GSM/PBX 

15 call control features. 

The user plane 510 and control plane 520 in a MINI-IP gateway environment 
500 are shown in Fig. 5. The control plane signaling 520 is needed because peer 
entities required to negotiate a channel for an "incoming call request" on an existing 
or on a new RTP/UDP connection. For example, a setup message will be 

20 transmitted upon receiving a call request from a PSTN/GSM/PBX user 530. The 
setup message include UDP connection identifiers and CID. The control signaling 
520 is carried by a TCP/IP connection 540 for assured data transfer. The user plane 
510 association is made after a successful connection setup. The user plane 510 data 
is carried over RTP/UDP/IP layers 542 similar to the audio and video transport over 

25 IP networks. 

The MINI-IP signaling works as follows. A call request from 
PSTN/PBX/GSM user 530 triggers a CID setup sequence between the peer MINI-IP 
controllers 550, 552. First, the MINI-IP controller 550 verifies if there is any 
existing RTP/UDP/IP connection to the remote gateway 560. If there is none or any 

30 existing connection(s) is full (no free CID) then the MINI-IP controller 520 

establishes a new RTP/UDP/IP connection. The new UDP connection is established 
throughout UDP sockets. If there exists a UDP connection and free CIDs for the call 
request, then MINI-IP uses the same UDP port number. A setup message is created 
with the local UDP port number, remote UDP port number, and CID number, and is 

35 transmitted to the remote gateway. 
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The remote gateway 560 recovers the information within the setup message 
and verifies that the requested CID is still free on its local table. If the call can be 
accepted then the local gateway 562 updates its local CID table and replies with a 
connect message. 

5 Fig. 6 illustrates an example of a CID table 600. In the CID table 600 of Fig. 

6, CID 25 610 is assigned and CID 26 612 is idle. The local UDP port number 620, 
remote port number 622, local user ID 624 and remote user ID 626 are provided for 
each CID that has been assigned. 

Referring again to Fig. 5, if the remote gateway 560 experiences any problem 
1 0 in allocating the connection, such as CID collision, then it transmits a reject 

message. The CID collision problem can be solved by existing schemes used in 
other protocols. Upon receiving a connect message, the local entity 562 confirms 
the CID association and informs the corresponding user 530. The MINI-IP 
signaling is closely associated with the call control signaling used in 
1 5 PSTN/GSM/PBX networks. The MINI-IP controller 550 establishes a user channel 
only within the IP network. Those skilled in the art will recognize that the call 
control signaling outside the IP network is beyond the scope of MINI-IP controller. 

At the time of assembling mini packets into an RTP payload, a timer controls 
the waiting time between the placement of a first packet in the RTP payload and the 
time to transmit the first packet to the remote peer. This timer (TIMER_MUX) is 
essential to control the delay accumulated at the multiplexing end for voice packets. 

Fig. 7 illustrates the use of the TIMER_MUX 700 according to the present 
invention. In Fig. 7, mini-packets 710 are received at a scheduler 712. The 
scheduler schedules packets for assembly into an RTP payload by placing packets 
into a packet assembly buffer 720. Upon expiration of the TIMER_MUX 730, an 
RTP packet is transmitted. The TIMERJMUX value depends on the link speed and 
transfer delay. The higher the TIMERJMUX value the better the bandwidth 
efficiency. However, higher TIMER_MUX value could increase the delay for voice 
packets. 

Speech is somewhat tolerant to packet loss when compared to data. But, 
beyond a certain limit, packet loss renders the speech inaudible and causes 
inconvenience to the user. Communication media are not error free and any data 
transmitted needs some sort of protection, j Existing protocols such as ATM, IP and 
AAL2 specify a Header Error Correction (HEC) to detect errors in the headers at the 
receiver. Protocols such as UDP offers both header and payload protection. The 
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*. 

UDP checksum is calculated for the entire UDP packet including header and 
payload. The MINI-IP header is 2 byte long and does not have any HEC field 
because MINI-IP packets are encapsulated within an RTP/UDP payload thus 
protected by the UDP checksum. 
5 Packet loss is another problem that is prevalent in any packet switching 

network. Since MINI-IP enables many users to share a single RTP/UDP/IP 
connection, MINI-IP can not use the RTP sequence number to identify packet loss 
of a single user. To solve this problem, the MINI-IP header consist of a two bit 
Sequence Number (SN) field. This two bit SN allows for a modulo 4 style sequence 
1 0 numbering at the transmitter. In general, SN could start at 0 and follow the sequence 
of 1,2,3,0,1,2. 

Accordingly, if there is a packet loss, then the MINI-IP controller could 
detect the loss at individual user level and take appropriate actions specified by the 
operator. As can be seen, this 2 bit field allows packet loss protection of up to 3 

1 5 consecutive packets at IP layer. 

Fig. 8 illustrates the application 800 of MINI-IP being restricted to transport 
voice users between IP telephony gateways. Some of the most obvious scenarios 
800 are shown in Fig. 8. Traditional telephony users such as PSTN 810 and PBX 
820 interconnected by IP telephone gateways 830 is an ideal scenario where MINI- 

20 IP improves the bandwidth efficiency of the IP network. MINI-IP can also be used 
in Radio Access Network (RAN) of a wireless network. 

Fig. 9 illustrates the application of a MINI-IP controller in a RAN 900. In 
this scenario, MINI-IP controller 910 is part of the BS 912 connected through IP 
network 920 to another MINI-IP controller 930 at the radio network controller/base 

25 station controller (RNC/BSC) 932. The base station controller 932 is coupled to a 
mobile switching center (MSC) 940 that includes a MINI-IP controller 942. The 
conversations of a number of GSM telephone users will be transported using IP 
telephony along with data traffic in the same IP network. Those skilled in the art 
will recognize that the present invention is not meant to be limited the particular 

30 components of the cellular system illustrated in Fig. 9. Rather, the MINI-IP is 

meant to be utilized in MINI-IP controllers in any component connected through a 
wireline or wireless IP network. 

As mentioned above, the important reason for multiplexing small packets 
into a single RTP payload is to reduce the RTP/UDP/IP overhead for each packet. 

35 For example, the overhead is 66.7% in case of 20 byte G.723.1 packet (40 byte 
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overhead/60 byte overhead + packet) and 80% for a 10 byte G.729 packet (40 byte 
overhead/50 byte overhead + packet). Considering that IP telephone gateways 
transfer hundreds of user at any given time, the overhead for all these users could 
very will exceed the total capacity of the link. However, the MINI-IP protocol 
5 described above reduces the overhead dramatically. 

Figs. 10-12 illustrate the differences in bandwidth requirement of MINI-IP 
and IP. The bandwidth requirement for a traditional scheme (RTP/UDP/IP) is 
compared to MINI-IP and the results are shown in Figs. 1 0 and 1 1 . 

Fig. 10 is a plot 1000 of the number of users 1010 on a single RTP/UDP/IP 
1 0 connection versus the bandwidth in Kbps 1 020 for G.723 . 1 , whereas Fig. 1 1 is a plot 
1 100 of the number of users 1 1 10 on a single RTP/UDP/IP connection versus the 
bandwidth in Kbps 1 120 for G.729. The rate of G.723. 1 is 5.6 Kbps and the rate of 
G.729 is 8 Kbps. The actual bandwidth requirement for increasing number of users 
is calculated by simply multiplying the number of users and the peak bandwidth. 
15 For example, the actual bandwidth requirement for 1 0 G.723 . 1 users is 56 Kbps. 
The bandwidth required by the traditional IP telephone method is calculated by 
adding the overhead of 66.7% (G.723.1) and 80% (G.729) per user. The bandwidth 
requirement for MINI-IP is calculated by adding the percentage of overhead due to 
multiplexing the number of users in a single UDP connection. The results indicate 
20 that the bandwidth requirement for transporting the same number of users through 
MINI-IP 1030, 1 130 is very low compared to the traditional IP (RTP/UDP/IP). 

The overhead 1200 of different speech codecs are shown in Fig. 12. The 
overhead due to RTP/UDP/IP is constant for both codecs since the RTP/UDP/IP 
overhead for each packet is constant. MINI-IP method is able to multiplex small 
25 packets into a single RTP/UDP/IP payload thus reducing the overhead to a 

minimum. The overhead due to MINI-IP 1230, 1240 on both codecs provides that 
MINI-IP is efficient in utilizing the bandwidth of the output link. In addition, as the 
number of users on a single connection increases, the overhead reduces further. 
Since MINI-IP utilize the bandwidth efficiently and does not generate as many 
30 individual IP packets, it avoids the congestion at intermediate IP routers. Also, high 
bandwidth efficiency allows the IP packets to be forwarded quickly within the 
network thus reducing the overall delay for speech packets. 

In summary, MINI-IP provides an increase in bandwidth efficiency between 
IP telephone gateways. MINI-IP allows many users to share a single RTP/UDP/IP 
35 connection, thus reducing the IP overhead for each packet. The codecs used in 
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telephone applications today generate an average packet size of 10 byte per speech 
sample. As shown above, the RTP/UDP/IP overhead per speech packet ranges from 
66% to 80%. This enormous overhead lowers the bandwidth efficiency as well, as 
causes congestion by generating large number of short IP packets. Traditional IP 
5 telephony gateways that interconnects PSTN/GSM/PBX systems do not utilize the 
bandwidth efficiently, whereas MINI-IP allows a number of users to share a single 
connection thereby reducing the overhead per packet transmitted. The assembly and 
de-assembly processing is compensated in case of MINI-IP because it does not 
require any separate UDP connection and complex signaling. 

10 MINI-IP provides a second advantage of reducing the number of UDP 

connections between gateways by sharing a single RTP/UDP/IP The third advantage 
is that the MINI-IP method reduces the changes for congestion at intermediate IP 
routers. MINI-IP reduces the number of IP packets by multiplexing mini packets in 
a single RTP payload, which helps to lower the congestion at the routers as well as 

1 5 reduces the complexity of IP packet forwarding. 

The foregoing description of the exemplary embodiment of the invention has 
been presented for the purposes of illustration and description. It is not intended to 
be exhaustive or to limit the invention to the precise form disclosed. Many 
modifications and variations are possible in light of the above teaching. It is 

20 intended that the scope of the invention be limited not with this detailed description, 
but rather by the claims appended hereto. 
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WHAT IS CLAIMED IS: ' 

1 . A protocol for increasing the bandwidth usage efficiency of a IP 
telephone network comprising: 

creating a header for a plurality of data packets, each header providing 
5 identification of a user associated with a packet; 

adding each header to the data packet associated therewith to form mini-IP 
payloads; 

multiplexing the mini-IP payloads into a RTP payload; and 
transmitting the RTP payload over a single RTP/UDP/IP connection. 

10 2. The protocol of claim 1 wherein the plurality of data packets are 

received from two or more users. 

3. The protocol of claim 2 wherein the identification of a user further 
comprises a unique channel identifier for each of the two or more users. 

4. The protocol of claim 3 wherein the channel identifier is assigned to 
1 5 packets from a user when the user requests access to the IP telephone network. 

5. The protocol of claim 2 wherein the header comprises a length 
indicator, the length indicator indicating the size of the data packet associated with 
the header. 

6. The protocol of claim 5 wherein the length indicator comprises six 
20 bits for allowing a maximum of a thirty-two byte data packet 

7. The protocol of claim 1 wherein the header further comprises a 
sequence number, the sequence number marking data packets transmitted from a 
user to identify data packet loss. 

8. The protocol of claim 7 wherein the sequence number further 

25 comprises two bits, the two bits identifying a maximum of three consecutive data 
packet losses. 

9. The protocol of claim 1 wherein the header of each data packet 
multiplexed into the RTP payload is transparent to intermediate IP routers. 

18 



BNSDOCID: <WO_ 



.001 1849A 1J_> 



WO 00/1 1849 PCT/US99/1 7389 

10. The protocol of claim 1 further comprising de-assembling the RTP 
payload back into the data packets. 



1 1 . The protocol of claim 1 further comprising: 
receiving at a local gateway an access request from a user at a remote IP 
5 gateway; 

transmitting a setup message to the remote IP gateway using an IP 
connection; and 

establishing a user plane connection for receiving data packets from a user 
after successful completion of a connection setup. 

10 12. The protocol of claim 1 1 further comprising: 

after receiving an access request from a user, determining whether an 
existing RTP/UDP/IP connection is available; 

using an existing RTP/UDP/IP connection when an existing RTP/UDP/IP 
connection is determined to be available; 
1 5 creating a new RTP/UDP/IP connection when an existing RTP/UDP/IP 

connection is determined not to be available; and 

creating a setup message using a local UDP port number, remote port 
number, and channel identifier. 

13. The protocol of claim 12 further comprising: 

20 recovering, at the remote gateway, a local UDP port number, remote port 

number, channel identifier from the setup message; 

verifying at the remote gateway whether the channel identifier is free; and 
accepting the connection when the channel identifier is free. 

14. The protocol of claim 13 wherein the accepting the connection further 
25 comprises: 

updating a channel identifier table at the remote gateway; 
replying to the local gateway with a connect message. 

1 5. The protocol of claim 14 further comprising replying to the local 
gateway with a rejection message when a problem allocating the connection occurs. 
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1 6. The protocol of claim 1 4 further comprising: 
receiving at the local entity the connect message; 
confirming at the local entity the channel identifier; and 
informing the user requesting access. 

5 17. The protocol of claim 1 further comprising controlling the 

multiplexing and transmitting of the RTP payload using a timer. 

1 8. The protocol of claim 1 wherein the data packets comprise 
compressed voice data. 



19. An IP telephone network, comprising: 
10 a remote IP gateway; and 

a local IP gateway; 

wherein the remote and local IP gateways communicate using a protocol, the 
protocol comprising: 

creating a header for a plurality of data packets received from a 
1 5 plurality of users at the local IP gateway, each header providing identification of a 
user associated with a packet; 

adding each header to the data packet associated therewith to form 
mini-IP payloads; 

multiplexing the mini-IP payloads into a RTP payload; and 
20 transmitting the RTP payload over a single RTP/UDP/IP connection 

to the remote IP gateway. 

20. The IP telephone network of claim 1 9 wherein the identification of a 
user further comprises a unique channel identifier for each of the two or more users. 

2 1 . The IP telephone network of claim 20 wherein the channel identifier 
25 is assigned to packets from a user when the user requests access to the remote IP 

gateway. 

22. The IP telephone network of claim 1 9 further comprising: 
receiving at the local IP gateway an access request from a user at the remote 

IP gateway; 

30 transmitting a setup message to the remote IP gateway using an IP 
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connection; and 

establishing a user plane connection for receiving data packets from a user 
after successful completion of a connection setup. 

23. The IP telephone network of claim 22 further comprising: 

5 after receiving an access request from a user, determining whether an 

existing RTP/UDP/IP connection between the local and remote IP gateways is 
available; 

using an existing RTP/UDP/IP connection when an existing RTP/UDP/IP 
connection is determined to be available; 
10 creating a new RTP/UDP/IP connection when an existing RTP/UDP/IP 

connection is determined not to be available; and 

creating a setup message using a local UDP port number, remote port 
number, channel identifier. 

24. The IP telephone network of claim 23 further comprising: 

1 5 recovering, at the remote IP gateway, a local UDP port number, remote port 

number, channel identifier from the setup message; 

verifying at the remote IP gateway whether the channel identifier is free; and 
accepting the connection when the channel identifier is free. 

25. The IP telephone network of claim 24 wherein the accepting the 
20 connection further comprises: 

updating a channel identifier table at the remote IP gateway; 
replying to the local IP gateway with a connect message. 

26. The IP telephone network of claim 25 further comprising replying to 
the local IP gateway with a rejection message when a problem allocating the 

25 connection occurs. 

27. The IP telephone network of claim 25 further comprising: 
receiving at the local IP gateway the connect message; 
confirming at the local IP gateway the channel identifier; and 
informing the user requesting access. 
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28. The IP telephone network of claim 1 9 wherein the data packets 
comprise compressed voice data. 



29. A MINI-IP controller, comprising: 

means for providing control plane signaling, control plane signaling being 
5 used to setup a connection to a remote peer MINI-IP controller; and 

means for providing user plane signal, user plane signaling being used to 
transmit data packets to a user associated with the remote peer MINI-IP controller 
using a MINI-IP protocol, the MINI-IP protocol comprising: 

creating a header for a plurality of data packets, each header 
1 0 providing identification of a user associated with a packet; 

adding each header to the data packet associated therewith to form 
mini-IP payloads; _ 

multiplexing the mini-IP payloads into a RTP payload; and 
transmitting the RTP payload over a single RTP/UDP/IP connection. 

1 5 30. The MINI-IP controller of claim 29 wherein the data packets 

comprise compressed voice data. 

31. An RTP payload, comprising: 
an RTP header; 

a plurality of data packets representing data from a plurality of users; and 
20 a plurality of MINI-IP headers, each of the plurality of packets having a 

MINI-IP header attached thereto, each of the MINI-IP headers comprising a user 
identifier for identifying one of the plurality of users being associated with each of 
the packets, and each MINI-IP header and packet combination forming a MINI-IP 
payload, the MINI-IP payloads being multiplexed together to form a RTP packet 

25 32. The RTP payload of claim 3 1 further comprising a UDP header. 

33. The RTP payload of claim 32 further comprising an IP header. 

34. The RTP payload of claim 3 1 wherein the identifier of a user further 
comprises a unique channel identifier for each of the two or more users. 
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35. The RTP payload of claim 34 wherein the channel identifier is 
assigned to packets from a user when the user requests access to an IP telephone 
network. 

36. The RTP payload of claim 35 wherein the MINI-IP header comprises 
5 a length indicator, the length indicator indicating the size of the data packet 

associated with the header. 

37. The RTP payload of claim 36 wherein the length indicator comprises 
six bits for allowing a maximum of a thirty-two byte data packet. 

38. The RTP payload of claim 3 1 wherein the MINI-IP header further 
10 comprises a sequence number, the sequence number marking data packets 

transmitted from a user to identify data packet loss. 

39. The RTP payload of claim 38 wherein the sequence number further 
comprises two bits, the two bits identifying a maximum of three consecutive data 
packet losses. 

15 40. The RTP payload of claim 3 1 wherein the MINI-IP header of each 

data packet multiplexed into the RTP payload is transparent to intermediate IP 
routers. 

41 . The RTP payload of claim 3 1 wherein the data packets comprise 
compressed voice data. 

20 42. An IP network, comprising: 

a base station having a MINI-IP controller; and 
a RNC having a MINI-IP controller; 

wherein the base station and the RNC communicate using a protocol, the 
protocol comprising: 

25 creating a header for a plurality of data packets received from a 

plurality of users at the RNC, each header providing identification of a user 
associated with a packet; 

adding each header to the data packet associated therewith to form 
mini-IP payloads; 
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multiplexing the mini-IP payloads into a RTP payload; and 
transmitting the RTP payload over a single RTP/UDP/IP connection 
to the base station. 

43 . The IP network of claim 42 wherein the identification of a user 
5 further comprises a unique channel identifier for each of the two or more users. 

44. The IP network of claim 43 wherein the channel identifier is assigned 
to packets from a user when the user requests access to the base station. 

45. The IP network of claim 42 further comprising: 

receiving at the RNC an access request from a user at the base station; 
10 transmitting a setup message to the base station using an IP connection; and 

establishing a user plane connection for receiving data packets from a user 
after successful completion of a connection setup. 

46. The IP network of claim 45 further comprising: 

after receiving an access request from a user, determining whether an 
1 5 existing RTP/UDP/IP connection between the RNC and base station is available; 

using an existing RTP/UDP/IP connection when an existing RTP/UDP/IP 
connection is determined to be available; 

creating a new RTP/UDP/IP connection when an existing RTP/UDP/IP 
connection is determined not to be available; and 
20 creating a setup message using a local UDP port number, remote port 

number, channel identifier. 

47. The IP network of claim 46 further comprising: 
recovering, at the base station, a local UDP port number, remote port 

number, channel identifier from the setup message; 
25 verifying at the base station whether the channel identifier is free; and 

accepting the connection when the channel identifier is free. 

48. The IP network of claim 47 wherein the accepting the connection 
further comprises: 

updating a channel identifier table at the base station; 
30 replying to the RNC with a connect message. 
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49. The IP network of claim 48 further comprising replying to the RNC 
with a rejection message when a problem allocating the connection occurs. 

50. The IP network of claim 48 further comprising: 
receiving at the RNC the connect message; 

5 confirming at the RNC the channel identifier; and 

informing the user requesting access. 

5 1 . The IP network of claim 42 wherein the data packets comprise 
compressed voice data. 

52. A base station having a MINI-IP controller for increasing the 
10 efficiency of bandwidth usage in a cellular network, the MINI-IP controller 

comprising means for providing control plane signaling, control plane signaling 
being used to setup a connection to a base station controller having a peer MINI-IP 
controller and means for providing user plane signal, user plane signaling being used 
to transmit data packets to a the base station controller using a MINI-IP protocol, 
15 the MINI-IP protocol creating a header for a plurality of data packets, each header 
providing identification of a mobile user associated with a packet, adding each 
header to the data packet associated therewith to form mini-IP pay loads, 
multiplexing the mini-IP payloads into a RTP payload and transmitting the RTP 
payload over a single RTP/UDP/IP connection. 

20 53 . The base station of claim 52 wherein the data packets comprise 

compressed voice data. 

54. A base station controller having a MINI-IP controller for increasing 
the efficiency of bandwidth usage in a cellular network, the MINI-IP controller 
comprising means for providing control plane signaling, control plane signaling 

25 being used to setup a connection to a base station having a peer MINI-IP controller 
and means for providing user plane signal, user plane signaling being used to 
transmit data packets to a the base station using a MINI-IP protocol, the MINI-IP 
protocol creating a header for a plurality of data packets, each header providing 
identification of a mobile user associated with a packet, adding each header to the 

30 data packet associated therewith to form mini-IP payloads, multiplexing the mini-IP 
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payloads into a RTP payload and transmitting the RTP payload over a single 
RTP/UDP/IP connection. 

55. The base station controller of claim 52 wherein the data packets 
comprise compressed voice data. 

5 56. A mobile switching center having a MINI-IP controller for increasing 

the efficiency of bandwidth usage in a cellular network, the MINI-IP controller 
comprising means for providing control plane signaling, control plane signaling 
being used to setup a connection to a base station controller having a peer MINI-IP 
controller and means for providing user plane signal, user plane signaling being used 

1 0 to transmit data packets to a the base station controller using a MINI-IP protocol, 
the MINI-IP protocol creating a header for a plurality of data packets, each header 
providing identification of a mobile user associated with a packet, adding each 
header to the data packet associated therewith to form mini-IP payloads, 
multiplexing the mini-IP payloads into a RTP payload and transmitting the RTP 

15 payload over a single RTP/UDP/IP connection. 

57. The mobile switching center of claim 52 wherein the data packets 
comprise compressed voice data. 
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